Skip to content

Conversation

peat-psuwit
Copy link
Contributor

updated_at could be after merged_at, e.g. for MRs that has
additional comments after it's merged. So, after filtering by
updated_after parameter, also do client-side filtering on merged_at
field.

Now, an interesting thing is that while GitLab offers
order_by='merged_at' (since GitLab 17.2 [1]), there's no merged_after
parameter that we can use. So we can't tell server to filter this for
us.

Also, Python cannot parse GitLab's spec-complient ISO8601 datetime until
3.11 [2]. Thus a library called dateutil is added as an external
dependency.

[1]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/147052
[2]: https://docs.python.org/3/whatsnew/3.11.html#datetime

`updated_at` could be after `merged_at`, e.g. for MRs that has
additional comments after it's merged. So, after filtering by
`updated_after` parameter, also do client-side filtering on `merged_at`
field.

Now, an interesting thing is that while GitLab offers
order_by='merged_at' (since GitLab 17.2 [1]), there's no `merged_after`
parameter that we can use. So we can't tell server to filter this for
us.

Also, Python cannot parse GitLab's spec-complient ISO8601 datetime until
3.11 [2]. Thus a library called `dateutil` is added as an external
dependency.

[1]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/147052
[2]: https://docs.python.org/3/whatsnew/3.11.html#datetime
It was not possible to order by `merged_at` field until GitLab 17.2,
released ~6 months ago (and is already EoL).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant